System and a method for accerating communication between client and an email server

ABSTRACT

The communication between a remote email or application program and the server to which it interfaces, such as a mailbox exchange server, is improved. The present invention operates by tricking or controlling the application program in such away that the application program operates as thought it is on-line although in actuality it is off-line. This is accomplished by spoofing the application program and as a result, the application program operates off-line but the user has on-line type experience. More specifically, the present invention replaces the MAPI/RPC as the transport provider while the user is operating the application program in an off-line mode. The data transfer between the email application program and the email server is handled by the present invention in the background. On the server end of the connection, the present invention operates to spoof the server and thus causes the server to operate as though the remote customer is an interactive user presently connected to the domain.

CROSS-REFERENCE TO RELATED APPLICATION

This application claims the priority of U.S. Provisional PatentApplication No. 60/346,683 filed Jan. 7, 2002, entitled “A SYSTEM AND AMETHOD FOR ACCELERATING COMMUNICATION BETWEEN CLIENT AND MS EXCHANGESERVER” and International Application Number PCT/IL03/00014 fled on Jan.5, 2003 and entitled “A SYSTEM AND A METHOD FOR ACCELERATINGCOMMUNICATION BETWEEN CLIENT AND AN EMAIL SERVER” the subject matter ofwhich are hereby incorporated by reference.

TECHNICAL FIELD

The present invention relates to the field of data communications and,more specifically, to the enhancement of transferring data throughput incommunication system between an Email Server and a client utilizingEmail software.

BACKGROUND OF THE INVENTION

Historically, in server based networks serving one or more clients, theservers have utilized powerful computers while the client computers haveutilized computers possessing limited computing power and limitedstorage capacity. Generally, communication between the clients and theservers has been enabled through the use of a LAN (Local Area Network)using a high capacity communication link and generating a domain.

A domain is a group of computers and devices on a network that areadministered as a unit with common rules and procedures. Within theInternet, domains are defined by the IP address that is assigned. Alldevices sharing a common part of the IP address are said to be in thesame domain.

Therefore, in client/server architectures, the storage and theprocessing is primarily performed on the server side while the clientcomputer operates as a terminal and an interface unit between the userand the server. Obviously, this type of an architecture results in heavytransportation of information between the client and the server. Itshould be noted that the terms “client” and “user” are usedinterchangeably herein.

In recent years, the portable computer has experienced explosive growthin utilization, as well as in the performance capabilities, features,processing power, memory availability and capabilities. There has alsobeen a great deal of expansion in use and availability of the globaldata communication network known as the Internet, and the use ofportable communication systems like, but not limited to, cellular orsatellite systems.

It is desirable for an enterprise that is using a client/serverarchitecture, for example MICROSOFT OUTLOOK and the MS exchange server,to provide users with the ability to access their MS Office documentsand E-mail messages while being out of the office and connected throughthe Internet via telephone lines or a wireless network, like but notlimited to Cellular or Satellite networks. Outlook is Microsoft's mailclient and personal information manager. The full version includes a PIM(Personal Information Manager) calendaring, to-do list and groupwarefunctions. OUTLOOK also provides a journaling capability for keepingtrack of hourly billing. OUTLOOK can be used as the client end toMICROSOFT'S Exchange Server or as the e-mail client with any ISP(Internet Service Provider) account. The paragraphs that follow refer toan MS exchange server as an example of an Email Server of the presentinvention, and to OUTLOOK as an example of an Email application.

One technical hurdle, in meeting this desire, is that the wirelesscommunication systems or networks have a limited bandwidth. Using suchlimited bandwidth networks to replace a LAN results in increasing thecommunication time between the remote users and reduces the quality ofthe connection.

Therefore there is a need in the art for a system and a method that canreduce the transportation between a remote user and a server in anon-line operation. Such a system can increase the speed of thecommunication. Further, there is a need in the art for a system andmethod to reduce the transportation between a remote user and a serverover a wireless communication channel.

A specific example of this need can be seen in the setting of a usermailbox within an exchange server. In this setting, the user mailbox ispart of the exchange server information store. The information storeconsists of three implementations of MAPI message stores: the publicinformation store, the private information store, and the personalfolder store (PST). MAPI is an abbreviation of Messaging ApplicationProgramming Interface, a system built into Microsoft Windows thatenables different e-mail applications to work together to distributemail. As long as both applications are MAPI-enabled, they can share mailmessages with each other. The paragraphs that follow refer to MAPI as anexample of an application programming interface of the presentinvention.

The information store organization of public folders, private folders,and messages is referred to as the organization hierarchy. Anotherimplementation of a MAPI message store is configured when a user worksoffline or not connected to the exchange server. This message store iscalled the offline folder store (OST) and the content and structure ofthe OST mirrors the mailbox while offline.

A mailbox is the delivery location for all incoming mail messagesaddressed to a designated owner. Information in a user's mailbox isstored in the private information store on a Microsoft Exchange Servercomputer. A mailbox can contain received messages, message attachments,folders, folder hierarchy, and more.

OUTLOOK uses MAPI over Remote Procedure Calls (RPC) as it's transportprovider to connect the user to its mailbox that resides physically atthe exchange server as part of the information store. RPC is a call thatis based on a client server model. Procedures that are called within theclient application are actually performed within the server side over acommunication channels. The MAPI transport provider and the MAPI messagestore, called the exchange server service, are tightly coupled in such away, that it is impossible to use only the MAPI message store and adifferent transport provider and still maintain the provision of all theservices the Exchange server service offers.

Using RPC as the communication between a remote user and its mailbox atthe exchange server over low bandwidth is very slow and has a lot ofcommunication overhead. When the user uses OUTLOOK in the offline mode,outgoing messages are kept in the user outbox in its offline folders,and incoming messages are kept for him at the exchange server. When theuser is going back online, the exchange server and outlook synchronizethose messages. This process results in a significant amount of datatransfer to occur, depending on the amount of traffic received and thetime that the user has been off line. In a wireless configuration, thisprocess can absorb a significant percentage of the available bandwidth.Thus, there is a need in the art for a method to reduce thetransportation between a remote user and a server in an on-lineoperation when large amounts of data, such as during a synchronizationfunction, is necessary.

SUMMARY OF THE INVENTION

The present invention provides a system and a method that improves theon-line operation between a remote email or application program and theexchange server to which it interfaces, such as a mailbox exchangeserver. The present invention operates by tricking or controlling theemail application program in such away that the email applicationprogram operates as it is on-line although it is off-line. In anembodiment of the present invention, this is accomplished by spoofingthe OUTLOOK application program and as a result, the OUTLOOK systemoperates off-line but the user has on-line type experience.

More specifically, the present invention replaces the MAPI/RPC as thetransport provider while the user is operating the email applicationprogram in an off-line mode. The data transfer between the emailapplication program and the email server is handled by the presentinvention in the background. On the server end of the connection, thepresent invention operates to spoof the server and thus causes theserver to operate as though the remote customer is an interactive userpresently connected to the domain.

Another aspect of the present invention is using the multi-taskingfeature of an NT machine to overcome the MAPI session limitation of anExchange Server. The Exchange Server operates to enable only a limitednumber of MAPI sessions per interactive user's computer. The presentinvention overcomes this limitation by generating a separate task foreach active remote user (a User Agent (UA)). This method of spoofing theExchange Server enables the Exchange server to support a plurality ofremote users via a single NT/Win2000 machine or equivalents.

An exemplary embodiment of present invention may include, but is notlimited to, two logical modules that work within the client/serverarchitecture:

(1) A Domain Logical Module (DM), which is installed on an NT machine orsimilar machine and has a computer account in the domain; and

(2) A Client Logical Module (CM), which is installed in the client'scomputer as an extension of the mail program.

The present invention may be a DLL OUTLOOK extension/add-in, andreplaces the MAPI/CDO as the transport provider. CDO, or CollaborationData Objects is a technology for building messaging or collaborationapplications. DLL is short for Dynamic Link Library, a library ofexecutable functions or data that can be used by a Windows application.Typically, a DLL provides one or more particular functions and a programaccesses the functions by creating either a static or dynamic link tothe DLL. A static link remains constant during program execution while adynamic link is created by the program as needed. DLLs can also containjust data. DLL files usually end with the extension “.dll”.

A DLL can be used by several applications at the same time. Some DLLsare provided with the Windows operating system and available for anyWindows application. Other DLLs are written for a particular applicationand are loaded with the application as in the exemplary embodiment ofthe present invention.

CDO is the bridge from Visual Basic and scripting languages to MAPI. CDOexposes COM objects, but these COM objects are of the right nature to beaccessible through both languages.

The present invention may be used in conjunction with an additionalsystem, which operates to accelerate the communication over aproblematic network channel such as, but not limited to cellular,satellite or other wireless channels. This additional system may operateto compress or otherwise modify the communication protocol to create amore efficient protocol or make other changes and adjustments. Examplesof such additional systems include NettGain 1100 of Flash Networks. Ifthe accelerating system is used, two additional modules may beneeded—one in each end of the problematic line. However, it should benoted that these additional modules are not required elements of thepresent invention but rather, can be incorporated into the presentinvention. These additional modules include:

Client Booster (C. BST).

Gateway Booster (G. BST).

The present invention supports substantially all OUTLOOK built-in forms,such as the E-mail messages, appointments, contacts, calendar, tasksetc.

Other objects, features, and advantages of the present invention willbecome apparent upon reading the following detailed description of theembodiments with the accompanying drawings and appended claims.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a block diagram illustrating a common environment in which anexemplary embodiment of the present invention may be used.

FIG. 2 a illustrates a block diagram of an exemplary embodiment of aClient Module (CM).

FIG. 2 b illustrates a block diagram of an exemplary embodiment of aClient Module (CM), which is connected to a booster module.

FIG. 3 illustrates a block diagram of an exemplary embodiment of aDomain Module (DM) in a corporate domain.

FIG. 4 a and FIG. 4 b are a flow chart illustration of a methodimplemented by an exemplary embodiment of the present invention duringthe login stage. FIG. 4 a illustrates a method implemented by anexemplary embodiment of a Client Module and FIG. 4 b illustrates amethod implemented by an exemplary embodiment of a Domain Module.

FIG. 5 illustrates a method implemented by an exemplary embodiment of aClient Module during on going operation after the Login stage.

FIG. 6 illustrates a method implemented by an exemplary embodiment of aUser Agent (UA) 360 during the on going operation, after the Loginstage.

FIG. 7 illustrates a method implemented by an exemplary embodiment of aUA 360 during A Logoff stage.

DETAILED DESCRIPTION

Referring now to the drawings, in which like numerals refer to likeparts throughout the several views, exemplary embodiments of the presentinvention are described.

FIG. 1 is a block diagram illustrating a common environment in which thepresent invention may be used. A cellular system 100 has been selectedas an exemplary environment that is suitable for implementing thepresent invention. However, it should be noted, and readily observableto those skilled in the art, that the present invention is not limitedto operation within a cellular environment, and for that matter, anyother specific communications system. But rather, the present inventioncan be implemented using various communication systems such as, but notlimited to, satellites, the PSTN (Public Switched Telephone Network),ISDN (integrated services digital network) lines etc.

A plurality of laptop computers 110 a to 110 n are connected viacellular connections 120 to a gateway (GW) 130, which can be located ina particular cell or in an operator station. The laptop computers 110may represent any portable devices that use MAPI messages services forcommunicate with an exchange server, like but not limited to palmcomputers, cellular phones etc., and will collectively be referred to asclient 110.

The communication over connection channels 120 can be based on TCP/IPor, it can be based on a proprietary accelerating protocol. In case ofusing a proprietary accelerating protocol, two additional modules areneeded (one for each end of the line 120).

GW 130 may be connected via a VWB (Very Wide Bandwidth) connection 140to the Internet 150 and from there, via the appropriate Domain Modules(DM), 160 a to 160 m, to the domain of each of the cooperates, 170 a to170 m, which comprises the appropriate Exchange Server, 175 a to 175 m.

More than one client 110 may be connected to the same domain 170 via thesame DM 160 and be engaged in an interactive connection with the sameExchange Server 175 simultaneously.

FIG. 2 a illustrates a block diagram of an exemplary embodiment of aClient Module (CM). The CM 205 is a OUTLOOK extension DLL. The CM 205operates to receive indications from OUTLOOK, or some other emailapplication program, when a new message has been submitted to theoutbox; change the message from the messaging application format into aproprietary messaging format (Msg. FT) and export the translated messageover TCP/IP.

The CM 205 comprises several modules including: Event Manager 207;format converter 210; Messaging System (Mes. Sys.) 220; priority queue(Q) 230 and TCP/IP module 240.

The User, operating an email application program in an off-line mode anddesiring to send an outgoing message, presses the send button, or itsequivalent, and the message is submitted to the outbox. The emailapplication program then indicates to its extensions that a new messageis waiting in the outbox. Upon receiving this indication, the EventManager 207 calls the Format Converter 210, which reads the new messagein MAPI format and translates it into the Mes. FT. The Mes. FT is achain of properties, which, among other things, includes the message.The format converter 210 which translates the MAPI message into the Mes.FT and vice versa, may select part of the properties that are sufficientto reconstruct the right message in the other side of the communicationchannel. Mes. Sys. 220 receives the chain of objects of the newconverted message, organizes it into a complete message and sends thecomplete message to the queue 230. By using a proprietary messagingformat, the present invention has the flexibility to be connected to amail client and personal information manager system, other than OUTLOOK,by simply modifying the Event Manager 207 and the Format Converter 210,to fit the API of the other mail system.

Queue 230 organizes the messages according to the priority that has beenchosen or selected by the user. Queue 230 is the buffer between OUTLOOKand the network. Transmitting and receiving of the messages aretransparent to the user, thus giving the user off-line operation with anon-line experience.

The output of the queue 230 is transferred to the TCP/IP module 240 thathandles the communication over TCP/IP from or to OUTLOOK. The TCP/IPmodule 240 picks a complete message from the queue 230 and transfers itover TCP/IP via the configured socket. The TCP/IP module 240 alsomaintains the connection and tries to reconnect to its defined socket incase the connection has been broken.

In the exemplary embodiment of FIG. 2 a, the message is then sent outover TCP/IP.

Alternatively, in the exemplary embodiment of FIG. 2 b, the message fromOUTLOOK is sent via TCP/IP to a booster unit 260 that translates theTCP/IP buffers into a more efficient protocol, manipulates the messageto accelerate the communication and sends the transformed message via aproprietary tunnel (BST connection) 265 to the GW 130.

In the other direction, when a message is received from the ExchangeServer 175 (FIG. 1), the TCP/IP module 240 handles the data on a packetbasis and transfers it to the input section of queue 230. The data fromqueue 230 is transferred to Mess. Sys. 220. The Mess. Sys. 220 gathersthe information from the relevant packets into the whole message andtransfers it to the format converter 210. The format converter 210translates the proprietary format back to the MAPI format, and themessage is then transferred to its destination (e.g. the inbox, thecalendar etc.). In parallel, the Event Manger 207 sends an indication tothe user that the message has arrived at client 110.

Incoming messages can occur in one of two methods. In one method, a newmessage notification has been sent to the user's mailbox within theExchange Server 175 and wakes up the user agent to start downloading themessage. In another method, the user presses the Send/Receive button onthe OUTLOOK menu when the OUTLOOK application is not connected. TheEvent Manager 207 that waits for this event, sends a refresh message tothe user agent to instruct the user agent to start download newmessages.

FIG. 3 illustrates a block diagram of an exemplary embodiment of aDomain Module (DM) 160 in a Corporate Domain 170. Corporate Domain 170comprises an Exchange Server 175 and an exemplary DM 160.

The DM 160 may be an NT machine, a Window 2000 machine etc., andcomprises several logical modules including: a TCP/IP module 340, a DMpriority queue (Q) 330, Dispatcher 350 with its Messaging System 352,and a plurality of User Agents (UA) 360.

On the upper side, the DM 160 is connected to an Exchange Server 175 andon the other side is connected to a plurality of clients 110 via TCP/IPconnection 345 over the Internet (not shown in FIG. 3). Because OUTLOOKin the client computer 110 is operating in off-line mode, thetransportation between the CM 200 and the DM 160 is carried by aproprietary Transport Provider over the TCP/IP connection 345.

The TCP/IP logical module 340 handles the incoming data from the remoteuser, via the configured socket, on a packet basis, processes themaccording to the protocol and transfers the data to the input section ofqueue 330. The TCP/IP module 340 also maintains the connection and triesto reconnect to its defined socket in case the connection has beenbroken.

The data from the input section of queue 330 is grabbed by theDispatcher Mess. Sys. 352. The Dis. Mess. Sys. 352 pulls theinformation, organizes it into a message and transfers the message tothe Dispatcher 350.

Dispatcher 350 reads the envelop of the message and, based on itscurrent dispatching list, determines whether the source of the messageis a new remote user 110. If the source of the message is a new user,the Dispatcher 350 assigns a free User Agent 360 to the new user, addsthis assignment to its dispatching list and submits the message to theselected UA 360. If the source of the message is not a new user, theDispatcher 350, based on the dispatching list, transfers the message tothe appropriate UA 360.

UA 360 represents its assigned user in front of the Exchange Server 175.The UA 360 performs login and logout in the name of current user of theremote client 110, spoofing the Exchange Server 175 into operating asthough the remote user is connected locally to the domain and operatingas an interactive user, who receives and transmits OUTLOOK messages andmail.

A UA 360 comprises of priority queue logical module 363, Mes. Sys.logical module 320, format converter logical module 310 and EventManager logical module 307.

Uploaded messages from the remote user are submitted by the Dispatcher350 to the input section of priority Queue 363 of the UA 360. MessagingSystem 320 pulls the information from the input section based on itspriority, organizes the information into a message in the proprietarymessaging format and transfers it to the Format Converter 310. FormatConverter 310 translates the proprietary messaging format into MAPI/CDOformat and transfers the message in MAPI format to the Event Manager307.

Upon receiving a new message from the remote user, the Event Manager 307determines whether the message is a Login-request or an Inter PersonalMessaging (IPM) message. If the message is a Login-request, the EventManager 307 impersonates as the remote user and performs a logonsequence to the Exchange Server 175 on behalf of this user. The EventManager 307 uses the credentials of the remote user that have beencollected by the Event Manager 207 of the CM 200 and initiates a MAPIsession in the Exchange Server 175. The operation of the UA EventManager 307 is described in more detail below.

Moreover, in some embodiments the: UA Event Manager 307, the FormatConverter 310 and the Mes. Sys. 320 may be combined into a singlelogical module or into two logical modules instead of the three modulesof the current exemplary embodiment.

Messages from the Exchange Server 175 to the remote users, which arecurrently connected to the DM 160, are processed by the appropriate UA360 and submitted to the output section of Priority Queue 330. Theoutput section of the Priority Queue 330 of the DM 160, collects theoutgoing messages from each UA 360. The outgoing messages, from PriorityQueue 330, preferably based at least in part on their priority, arepulled and processed by TCP/IP logical module 340 and are sent aspackets over TCP/IP to the appropriate user of remote client 110.

Alternatively, in another exemplary embodiment (not shown in thedrawings) a booster unit may be used between the TCP/IP logical module340 and the network. This booster unit manipulates the transportationinto a more efficient protocol, manipulates the message to acceleratethe communication and sends the transformed message via a proprietarytunnel (BST connection) to the GW 130. This unit may perform thecomplementary operations of the booster unit 260 in FIG. 2 b.

As part of the installation process of the CM in its computer, the useris required to select one of its on-line OUTLOOK profiles. The user maygenerate this profile by using the Windows Mail Configuration within thecontrol panel.

FIG. 4 a is a flow chart illustrating one method for implementing anexemplary embodiment of a CM 205 (FIGS. 2 a&2 b) during the login stage.The OUTLOOK application, upon initiation by the user, prompts the userat step 410 to select one of the OUTLOOK Profiles. At step 420, if theselected profile is a profile that does not invoke the presentinvention, the CM 205 is not initiated and processing continues at step422 where the user may use OUTLOOK in its common way of operation.

If at step 420 the selected profile is a profile that invokes thepresent invention, the CM 205, at step 424, starts the Login processwith the user. This step includes prompting the user with a login dialogbox, in which the user is required to enter his credentials (user name,password domain name and the Exchange Server name). In one embodiment,the CM 205 may be configured to take these credentials from the userprofile without prompting the user for the dialog box.

The user credentials with additional configuration parameters (forexample: compression attributes, the last synchronization time etc.) aresent over the network to the DM 160 (FIG. 1) at step 427, using the TCPconnection 250 (FIGS. 2 a&2 b) or via a booster system 260 in case thatsuch a system exists. Then the CM 205 is waiting 429 for receiving aresponse from DM 160.

FIG. 4 b is a flow chart illustrating one method for implementing anexemplary embodiment of a DM 160 during the login stage. Upon receivinga Login request from a remote user, the Dispatcher 350 (FIG. 3) verifies(not shown in the drawing) whether the remote user has been assigned aUA 360 (FIG. 3). If the remote user has been assigned a UA 360, theDispatcher 350 forwards the request to the appropriate UA 360. If thereis no assignment yet, at step 430 the Dispatcher 350 determines whetherthere is a free UA. If there are no free UAs, at step 432 the Dispatcher350 waits until a time-out expires and then rechecks for a free UA atstep 430 again. If there is a free UA 360, at step 434 the Dispatcher350 assigns the client to the UA 360, updates its assignment table andforwards the call to the selected UA 360.

Upon receiving the Login-request, at step 440 the Event Manager 307 ofthe selected UA 360 determines whether it is the first Login-request ofthis user 110. If this is not the first Login-request, at step 448 theEvent Manager 307 (FIG. 3) updates the connection parameters andprocessing continues at step 456 and retrieves new mail.

However, if it is the first Login-request of a new user 110 (FIG. 1),processing continues at step 442 where the selected UA 360 gets thecurrent client's parameters and starts the impersonation process at step444. During the impersonation process, the UA 360 performs an NT loginto the domain 170, and impersonates the remote user 110 by using theclient credentials. The UA 360 then creates an OUTLOOK profile for thisnew client, on the machine on which the DM 160 runs, pretending that itis the remote client and at step 446, starts a MAPI session to theExchange Server.

At step 450, if the credentials of the user are valid and the loginsucceeds, at step 454 the UA 360 sends a Login-success message to the CM205 and the CM 205 processing continues at point B in FIG. 4 a. Inparallel, the UA 360 processing continues at step 456 to synchronizesthe mailbox.

At step 450, if the credentials of the user are not valid and the loginfails, the UA 360 enters the login fail process at step 452 which sendsa Login-fail message to the CM 205 and causes the CM 205 to continueprocessing at point B in FIG. 4 a. Then, the UA 360 provides notice tothe Dispatcher 350 about the disconnection and enters into a freeposition. The Dispatcher 350 updates its assignment table by removingthis assignment.

At step 456 the UA 360 retrieves all new messages, which have arrived tothe user's mailbox (within the exchange server) between the last loginand the current login, and sends these messages to the remote client 110via the CM 205. Then at step 458, the UA 360 registers itself for newmessage notification within the user's mailbox.

From this point forward, as long as there is a valid connection betweenthe client 110 and the DM 160, the new messages will be automaticallydownloaded to the user's off-line mailbox through the DM 160 and CM 205(FIGS. 2 a&2 b).

Returning now to the operation of the CM 205, FIG. 4 a point B, uponreceiving the response for the Login-request, at step 470 the CM 205determines whether the login has been successful. If the login has beensuccessful, at step 474 the CM 205 waits for the next event, which maybe incoming mails from the Exchange Server or outgoing messages from theuser 110. If the login fails, the CM 205 sends 478 a Login-failindication to the user 110 and processing continues at step 424 wherethe CM 205 prompt the user to login again.

FIG. 5 illustrates a method implemented by an exemplary embodiment of aCM 205 during the on going operation after the login stage. Initially,the CM 205 is waiting for a notification that an event has occurred.Upon receiving an event notification, at step 510 the CM 205 determineswhether the event arrived 520 from the OUTLOOK outbox or from 540 theTCP/IP connection.

If the event arrives from the OUTLOOK outbox, which means that the userhas sent a new message, processing continues at step 522. The newmessage may be mail, calendar, task etc. At step 522, the CM 205 grabsthe message from the outbox and pushes it via the chain comprising theFormat Converter 210, the Mes. Sys. 220, the output section of priorityqueue 230 and the TCP/IP module 240 and at step 530 sends the messageover the network as described above in conjunction with FIG. 2 a. The CM205 then returns to step 510 to wait for the next event.

If the event arrives from the TCP/IP connection indicating that newmessage arrives from DM 160 (FIG. 1), processing continues at step 542.The message may be a mail, calendar, task etc. message. At step 542, theCM 205 grabs the message via the chain as described above, and at step544 determines the type of the message. If the type of the message 560is mail or calendar, at step 562 the CM 205 pushes the message into theinbox of the remote client 110 and at step 564, sends an indication tothe user. Then the CM 205 returns to step 510 and waits for the nextevent.

If the type of the message is an error message 570, at step 576 the CMtries to reconnect again by returning to step 424 in FIG. 4 a andcontinues from there. If the type of the message is login feedback 550from the DM 160, at step 552 the CM 205 performs the part of theprocess, which is described above in conjunction to FIG. 4 a, from pointB.

FIG. 6 illustrates one method for implementing an exemplary embodimentof a UA 360 (FIG. 3) during the on going operation, after the loginstage. Initially, UA 360 is waiting for an event to occur. Uponreceiving notification that an event has occurred, at step 610 the UA360 determines whether the event arrived from the Exchange Server 175(FIG. 1) (step 620) or from the Dispatcher 350 (FIG. 3) (step 640).

If the event 620 arrives from the Exchange Server 175, it means that theclient 110 has received a new message. The new message may be mail,calendar etc. At step 622, the UA 360 grabs the message from the inboxof the relevant client 110 in the Exchange Server 175, and pushes it viathe chain comprising the Format Converter 310 (FIG. 3), the Mes. Sys.320 (FIG. 3), the output section of priority queue 330 and the TCP/IPmodule 340 (FIG. 3), and at step 630 sends the message over the networkas described above in conjunction with FIG. 3. Then, the UA 360 returnsto step 610 and waits for the next event.

If the event 640 arrives from the Dispatcher 350, it means that theclient has sent this new message. The message may be a mail, calendar,login request etc. At step 542, the UA 360 grabs the message via thechain as described above and at step 644 determines the type of themessage. If the type of the message is mail or calendar or etc. 660,then at step 662 the UA 360 submits it into the outbox in the ExchangeServer 175 associated with the user 110. The Exchange Server 175(FIG. 1) takes responsibility to deliver the message to its destination.

If the type of the message is a disconnection message 650, then the UA360 closes the MAPI session with the Exchange Server 175 and clears upthe allocated resources. Then the UA 360 provides notice to theDispatcher 350 that the connection is broken and waits for newassignment.

If the type of the message is Login-request 680 from the CM 205, then atstep 682 the UA 360 performs 682 the part of the login process, which isdescribed above, in conjunction to FIG. 4 b. At the end of the loginprocess, the UA 360 returns to step 610 and waits for the next event.

FIG. 7 illustrates one method for implementing an exemplary embodimentof a UA 360 during the Logoff stage. This routine is initiated uponreceiving a disconnection indication 720 from the TCP/IP module 340.Otherwise the UA 360 continues in its on going operation as describedabove in conjunction to FIG. 6. Upon receiving a disconnectionindication 720, the UA 360 starts several operations for terminating theon-line operation within the Exchange Server. First of all, at step 725the UA 360 unregisters itself from event notifications that occur in themailbox at the Exchange Server 175. Then at step 730, the UA 360 closesthe MAPI session within the Exchange Server 175. Upon terminating thelogoff process within the Exchange Server 175, at step 750 the UA 360notifies the Dispatcher 350 that it is free again and at step 760 waitsfor the next assignment.

In the description and claims of the present application, each of theverbs, “comprise” “include” and “have”, and conjugates thereof, are usedto indicate that the object or objects of the verb are not necessarily acomplete listing of members, components, elements or parts of thesubject or subjects of the verb.

The present invention has been described using detailed descriptions ofembodiments thereof that are provided by way of example and are notintended to limit the scope of the invention. The described embodimentscomprise different features, not all of which are required in allembodiments of the invention. Some embodiments of the present inventionutilize only some of the features or possible combinations of thefeatures. Variations of embodiments of the present invention that aredescribed and embodiments of the present invention comprising differentcombinations of features noted in the described embodiments will occurto persons of the art. The scope of the invention is limited only by thefollowing claims.

1. A system for enabling the exchange of data between at least oneremote user having a client application program running in an off-linemode and a server communicatively coupled to the application programover a network, said system comprising: a client logical module adaptedto: receive user credentials; detect the generation of an outgoingmessage generated through the application program; transfer the outgoingmessage over the network to a domain module; receive incoming messagesfrom the domain module; and transfer the incoming messages to theapplication program while the application program is operating in anoff-line mode; a domain module communicatively coupled to the clientlogical module and operating in association with the server, said domainmodule being adapted to: impersonate the remote user, thereby appearingto the server as though the application program is connected directly tothe server in an on-line mode; receive outgoing messages from the clientlogical module; transfer the outgoing messages to the server; receive amessage from the server; and provide the received messages to the clientlogical module in the remote client.
 2. The system of claim 1, whereinthe network is a TCP/IP network.
 3. The system of claim 1, wherein theapplication program is an email application program.
 4. The system ofclaim 3, wherein the email application program is OUTLOOK.
 5. The systemof claim 1, wherein the domain module is further adapted to impersonatethe remote user by performing a login procedure on behalf of theapplication program, thereby opening a communication session between theclient logical module and the server.
 6. The system of claim 4, whereinthe communication session between the the client logical module and theserver is a MAPI session.
 7. A method for exchanging data between aplurality of remote clients, each remote client running an emailapplication program in an off-line mode, and a server in a domain whichis connected to the remote clients over a TCP/IP network, said methodcomprising the steps of: sending a login request from at least one ofthe plurality of remote clients to a domain module; in response toreceiving the login request, said domain module impersonating the remoteclient by logging into the server serving the remote client; opening acommunication session between the remote client and the server; andtransferring messages between the remote client and the server via thedomain module, whereby the email application program appears to operateas though it is on-line with the server.
 8. The method of claim 7,wherein the remote client includes a client logical module, and the stepof sending the login request further comprises the steps of: receivingcredentials from the remote client; and the client logical moduleforwarding the login request with the credentials to the domain module.9. The method of claim 7, wherein the server is an exchange server. 10.The method of claim 7, wherein the communication between the domainmodule and the server is using MAPI.
 11. A system for enhancingperceived throughput between a plurality of remote clients running anOUTLOOK application and an exchange server in a domain which isconnected to the remote clients over a TCP/IP network, said systemcomprising: a client logical module for each remote client, the clientlogical modules being adapted to: receive credentials for a user of theremote client; receive outgoing messages from a remote client outbox andto transfer the outgoing messages over the TCP/IP network to a domainmodule; and receive messages from the domain module and transfer them toa remote client inbox in the OUTLOOK application while the OUTLOOKapplication is operating in an off-line mode; a domain module, which isconnected between said TCP/IP network and the domain, for each saidplurality of remote clients, said domain module being adapted to:impersonate the remote client by spoofing the exchange server to operateas though the remote client is connected directly to the domain; logininto the exchange server using the credentials of the user of the remoteclient; open a MAPI session for the remote client; receive messages fromthe client module of the remote client; transfer OUTLOOK messages to theexchange server; receive messages destined to a remote client from theexchange server; and submit the messages to the appropriate clientmodule of the destined remote client, whereby using said system allowsthe delivery of messages between the plurality of remote clients and theexchange server in an off-line mode of operation of the OUTLOOKapplication without having to modify the exchange server.
 12. A methodfor exchanging data between a remote client running an applicationprogram in an off-line mode, and a server operating within a domain towhich the remote client is communicatively coupled, said methodcomprising the steps of: receiving credentials for a user of the remoteclient; detecting a message from the application program that isdirected to the server; reformatting the message from MAPI format to aproprietary format; transferring the message to the server over acommunication channel; detecting the reception of the message at thedomain; reformatting the reformatted message from the proprietary formatto the MAPI format to create a MAPI message; and providing the MAPImessage to the server.
 13. The method of claim 12, further comprisingthe steps of: sending a login request to the server; in response toreceiving the login request, emulating the actions that would normallybe taken by the application program to login to the server; and openinga MAPI session between the application program and the exchange server,whereby the application program appears to operate as though it ison-line with the server.
 14. The method of claim 12, wherein a MAPIsession exists between the application program running on the remoteclient and the server to facilitate communication of messages, furthercomprising the steps of: sending a disconnect request to the server; inresponse to receiving the disconnect request, emulating the actions thatwould normally be taken by the application program to logoff the server;and closing the MAPI session between the application program and theexchange server.
 15. The method of claim 12, further comprising thesteps of: detecting a message from the server that is directed to theapplication program; reformatting the message from MAPI format to aproprietary format; transferring the message to the application programover a communication channel; detecting the reception of the message atthe remote client; reformatting the reformatted message from theproprietary format to the MAPI format to create a MAPI message; andproviding the MAPI message to the application program.
 16. The method ofclaim 15, wherein the application program is an email applicationprogram and the step of providing the MAPI message to the applicationprogram comprises placing the MAPI message into the inbox of the emailapplication program.
 17. The method of claim 12, wherein the applicationprogram is an email application program and the step of detecting amessage from the application program comprises detecting a new messagein the outbox of the email application program.
 18. The method of claim17, wherein the email application program is OUTLOOK, further comprisingthe steps of: receiving a profile selection, the profile selection beingassociated with enabling the off-line operation; and enabling theoff-line operation in conjunction with the profile selection.
 19. Themethod of claim 17, wherein the email application program is OUTLOOK,further comprising the steps of: receiving a profile selection, theprofile selection not being associated with enabling the off-lineoperation; and disabling the step of detecting a message from theapplication program that is directed to the server.